…ers -> .users)

authMiddleware backfills blockchainUserId/handle for users whose identity
row lacks them (the state of any guest / freshly signed-up user) by calling
the SDK. It used `req.app.get('audiusSdk').full.users.getUserAccount(...)`,
but the @audius/sdk instance has no `.full` namespace - `users` is a
top-level API. So `.full` is undefined and `.users` throws a synchronous
TypeError ("Cannot read properties of undefined (reading 'users')") on
EVERY new-user auth request (/users/update, /record_ip, etc).

Confirmed in prod logs:
  TypeError: Cannot read properties of undefined (reading 'users')
    at authMiddleware (build/src/authMiddleware.js:97:68)
  msg: "Failed to update blockchainUserId/handle"

The bad accessor came in with the monorepo import (#14388) and only began
firing once #14474 (6/15) made loadAudiusSdk.cjs available so the SDK
actually initialized - matching the signup regression window. The
surrounding try/catch swallowed the error and called next(), so the
backfill silently never happened for new users.

Fix: use the correct accessor `audiusSdk.users.getUserAccount`. Also wrap
the now-live call in a 3s timeout (deferred into a promise so a
missing/misshapen sdk rejects instead of throwing synchronously), so that
once the call actually runs, a slow discovery lookup for a not-yet-indexed
new user degrades gracefully (logged, then next()) instead of stalling auth.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ers -> .users)

authMiddleware backfills blockchainUserId/handle for users whose identity
row lacks them (the state of any guest / freshly signed-up user) by calling
the SDK. It used `req.app.get('audiusSdk').full.users.getUserAccount(...)`,
but the @audius/sdk instance has no `.full` namespace - `users` is a
top-level API. So `.full` is undefined and `.users` throws a synchronous
TypeError ("Cannot read properties of undefined (reading 'users')") on
EVERY new-user auth request (/users/update, /record_ip, etc).

Confirmed in prod logs:
  TypeError: Cannot read properties of undefined (reading 'users')
    at authMiddleware (build/src/authMiddleware.js:97:68)
  msg: "Failed to update blockchainUserId/handle"

The bad accessor came in with the monorepo import (#14388) and only began
firing once #14474 (6/15) made loadAudiusSdk.cjs available so the SDK
actually initialized - matching the signup regression window. The
surrounding try/catch swallowed the error and called next(), so the
backfill silently never happened for new users.

Fix: use the correct accessor `audiusSdk.users.getUserAccount`.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

…ers -> .users) (#14482)

## Problem

Users report failing/janky signups, with `POST
https://identityservice.audius.co/users/update` misbehaving ([Slack
thread](https://audius-internal.slack.com/archives/CA80RCL77/p1781637102823139)).

`authMiddleware` (which gates `/users/update`, `/record_ip`, and every
other authenticated endpoint) backfills `blockchainUserId`/`handle` for
any identity `Users` row that lacks them — i.e. **every guest / freshly
signed-up user**. It did this via:

```js
req.app.get('audiusSdk').full.users.getUserAccount({ ... })
```

But the `@audius/sdk` instance **has no `.full` namespace** — `users` is
a top-level API (`audiusSdk.users.getUserAccount`). So `.full` is
`undefined` and `.users` throws a **synchronous `TypeError`** on every
new-user auth request.

Confirmed in prod logs:

```
TypeError: Cannot read properties of undefined (reading 'users')
    at authMiddleware (build/src/authMiddleware.js:97:68)
msg: "Failed to update blockchainUserId/handle"
```

The surrounding `try/catch` swallowed it and called `next()`, so the
request proceeded but the **backfill silently never happened** — new
identity rows never got `blockchainUserId`/`handle` set.

## Why it started now

The bad accessor came in with the **monorepo import** of
identity-service (#14388, 5/22), which rewrote `authMiddleware` to use
`@audius/sdk`. It was dormant until #14474 (6/15) shipped
`loadAudiusSdk.cjs` into the build, so the SDK actually initialized and
this line began firing — matching the regression window. (identity
hadn't been deployed in a while; 6/15 was the first monorepo image
promoted to prod.)

I verified prod is in the *benign* config otherwise:
`environment=production` is set in `identity-service-secret`, so the SDK
targets prod discovery — the issue is purely the wrong accessor, not SDK
misconfig.

## Fix

Use the correct accessor `audiusSdk.users.getUserAccount` in both
`authMiddleware` and `parameterizedAuthMiddleware`. One-token change per
call site.

## Notes
- Ray's `record_ip` hunch is a red herring: `/users/update` doesn't call
`recordIP`. (Though `/record_ip` is also gated by `authMiddleware`, so
it hit the same TypeError — likely the source of the confusion.)
- Same 6/15 batch also fixed a related latent crash: #14378 reads
`src/data/disposable_email_blocklist.conf` at signup via an unguarded
`fs.readFileSync`; that file wasn't copied into the build until #14474
(same one-liner that also added `loadAudiusSdk.cjs`). Worth hardening
that read separately.
- The batch's endpoint removals (#14458, #14472) are safe — the legacy
`packages/libs` methods that hit them aren't called by any current
client.

## Verification
- Confirmed `getUserAccount` lives on the top-level `UsersApi`
(`audiusSdk.users`) and there is no `.full` in the SDK instance shape
(`@audius/sdk` `index.d.ts`).
- Confirmed response shape `res.data.user` is still correct
(`UserAccountResponse.data: Account`, `Account.user: User`).
- Confirmed prod `environment=production`.

After deploy, the `TypeError ... reading 'users'` log should disappear
and `Failed to update blockchainUserId/handle` should drop to near-zero.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>